Table des matières

4.1. Gestion de la sécurité informatique

Garantir la sécurité d’un système ou d’une infrastructure informatique n’est pas chose facile : il faut tenir compte de nombreux facteurs, certains connus, d’autres moins, voire pas du tout. Il faut également travailler dans un cadre budgétaire contraint, et il y a donc des arbitrages à effectuer afin de s’assurer d’effectuer les choix les plus opportuns en fonction des objectifs poursuivis.

La réflexion quant aux processus et contre-mesures à mettre en place doit être menée le plus tôt possible, pour permettre une mise en oeuvre initiale efficace, mais elle ne s’arrête pas là : elle doit aussi prévoir la gestion à long terme des contre-mesures et processus choisis, la réaction aux incidents, et s’adapter à l’évolution des besoins, des infrastructures, mais aussi des menaces.

Cette réflexion est propre à chaque organisation et à son contexte : chacune sera plus ou moins vulnérable à certains risques, ou ses dirigeants plus ou moins prêts à accepter un niveau de risque donner.

Différentes méthodologies existent pour aider les organisations à réaliser cette réflexion visant à une gestion des risques informatiques. Il s’agit par exemple de la norme ISO27005 ou encore du NIST Cybersecurity Framework.

Nous allons, dans ce chapitre, brosser un petit aperçu de ce type de démarche. Nous allons plus spécifiquement parcourir quelques étapes permettant d’effectuer ce que nous appellerons une analyse des risques. Une analyse de risques en sécurité informatique consiste à identifier les risques encourus par une infrastructure informatique et à mettre en oeuvre un ensemble de contre-mesure, sur le court, moyen et long terme, pour contrer ces risques et mener une politique de sécurité adéquate par rapport aux besoins et au budget.  

Ces étapes seront au nombre de six :

  1. Identifier les biens à protéger
  2. Lister les vulnérabilités et menaces pesant sur ces biens
  3. Evaluer les risques
  4. Choisir et mettre en oeuvre des contre-mesures pour contrer les risques
  5. Prévoir les risques résiduels et organiser la réaction en cas d’incident (détection, réaction et récupération)
  6. Evaluer et maintenir les contre-mesures

Comme mentionné plus haut, cette gestion de risques s’effectue sur la durée, et non ponctuellement. Elle sera donc appliquée de manière itérative, dans un processus d’amélioration continue. Dans l’idéal, elle doit avoir lieu dès la mise en place d’un projet, pour intégrer la sécurité dès la conception (“security by design”).

4.1.1. Identification des biens

Une analyse de sécurité commence par identifier les biens (assets en anglais) qui doivent être protégés. Il peut s’agir de biens physiques, de biens logiques (données), ou de biens immatériels, comme la réputation d’une personne ou d’une entreprise.  Ces biens peuvent éventuellement être classés par ordre de valeur pour l’organisation.

4.1.2. Vulnérabilités et menaces

Pour chaque bien, il s’agit d’identifier les vulnérabilités auxquelles il est sujet. Une vulnérabilité est une faille, soit au niveau du bien lui-même (ex : faille logicielle), soit au niveau de facteurs externes auxquels il est soumis (ex : inondations). Notez qu’en plus des biens, les contre-mesures de sécurité elles-mêmes peuvent également être sujettes à des vulnérabilités.

Lorsqu’une vulnérabilité est susceptible d’être exploitée par une personne malveillante dans le cadre d’une attaque concrète, on parle alors de menace.

Pour aider à lister ces vulnérabilités, il peut être intéressant de réfléchir sur base de la triade “CIA” : pour chaque bien (éventuellement décliné en données et en service), on réfléchit aux enjeux en termes de Confidentialité, Intégrité et Disponibilité.  Pour aider à cette réflexion, des listes de menaces sont partagées par des experts en cybersécurité.  Citons notamment l’OWASP, pour ce qui est sécurité du Web. 

4.1.3. Analyse des risques

Afin de pouvoir décider quelles contre-mesures il faut mettre en place prioritairement, il convient d’évaluer, pour chaque menace identifiée, quel est le risque qu’elle entraîne. Ce risque dépend de plusieurs facteurs, dont la probabilité d’occurence et l’impact. Une menace peu probable et qui, si elle se réalise, n’entraîne qu’un petit désagrément ne vaut peut-être pas la peine qu’on y investisse de l’argent. Par contre, une menace relativement probable, mais qui impacterait sévèrement le fonctionnement de l’entreprise doit être sérieusement considérée. C’est par exemple le cas pour le site d’e-commerce d’une entreprise dont la majorité du chiffre d’affaire s’effectue par ce canal : toute indisponibilité du site entraîne une perte sèche pour l’entreprise.

On définira donc le risque comme étant le produit de la probabilité et de l’impact d’une menace.
Une fois les risques identifiés et textuellement détaillés, ils sont résumés dans un tableau, qui peut alors être classé en fonction du niveau de risque. Le tableau ci-dessous présente une classification de risques pour un serveur web interne hébergé dans le local serveur d’une entreprise.  Notez que cet exemple est purement fictif, superficiel et non exhaustif, et sert juste à illustrer la manière de présenter le tableau.  

# Menace Probabilité Impact Estimation du risque Contre-mesure
1 Perte de données (panne disque par ex.) Moyenne Fort Elevé Backup hors site
2 Injections SQL Moyen Faible (pas d’information critique dans la DB) Moyen Sécurisation des champs d’input
3 Accès non autorisé depuis le réseau moyenne Fort Elevé Sécurisation des accès administrateur et ségrégation en VLANs
4 Intrusion physique dans le local serveur moyenne Fort Elevé Accès protégé au local
5 Déni de service (ne peut provenir que du réseau interne) Faible Faible (service non essentiel au fonctionnement de l’entreprise) Faible Système de détection de DoS
Exemple de tableau des risques

Dans cet exemple, nous utilisons des niveaux qualitatifs. C’est évidemment assez subjectif comme estimation. Cela permet néanmoins de prioriser les contre-mesures : les menaces #1, #3 et #4 doivent être contrées en priorité.

Dans les méthodologies “officielles”, des métriques qualitatives ou quantitatives peuvent être utilisées, mais cela sort du cadre de ce cours introductif.

4.1.4. Contre-mesures

Une fois les risques classés, on identifie les contre-mesures à mettre en place, et on choisit celles qui seront mises en oeuvre, en fonction du budget et des ressources humaines disponibles.  

Ces contre-mesures peuvent concerner plusieurs éléments :

  • Les personnes : il faut s’assurer de former et sensibiliser le personnel aux procédures à mettre en oeuvre pour garantir la sécurité. Il s’agit par exemple de politique liée aux mots de passe.
  • Les éléments physiques : Gérer l’accès aux bâtiments et au matériel informatique, l’électricité, la climatisation, …
  • Les éléments informatiques : Machines, équipement réseaux, communications, …

Pour chaque contre-mesure, on s’assurera également de bien mettre en place tout ce qui est nécessaire pour garantir son bon fonctionnement sur le long terme :

  • Validation de son fonctionnement au moment du déploiement
  • Documentation
  • Maintenance (mises à jour)
  • Monitoring
  • Vérification régulière et ajustement

4.1.5. Gestion des risques résiduels et procédures de détection/réaction/récupération

Tous les risques ne seront pas identifiés ou contrés, donc il est important de se prémunir contre ce qu’on appelle les risques résiduels. Ces derniers sont soit des risques identifiés mais non mitigés par des contre-mesures, soit des risques non connus (failles zero-day par ex. ). Dans le premier cas, il importe de les documenter sérieusement, mais dans les deux cas, la seule solution est de travailler non pas à la prévention, mais plutôt à la réaction face à une attaque. L’objectif est alors de minimiser l’impact global de cette attaque, en mitigeant les dégâts et en rétablissant au plus vite le fonctionnement de l’organisation (business continuity). Idéalement, l’organisation devrait disposer d’un plan de reprise d’activité (Disaster Recovery Plan) pour définir les démarches à réaliser dans ce cas de figure.

Deux métriques sont souvent utilisées pour la planification de la gestion en cas d’attaque : le RPO et le RTO.

  • RPO : Recovery Point Objective : Durée maximum de données que l’organisation accepte de perdre lors d’une panne. La définition de cette métrique permettra notamment de définir une politique de backup adéquate.
  • RTO : Recovery Time Objective. Il s’agira de la durée maximum admissible d’indisponibilité d’un système informatique. Cette durée inclura la détection, l’analyse, la réaction et la mise en oeuvre des plans de secours, jusqu’au rétablissement du fonctionnement de la ressource considérée.

Pour pouvoir réagir à une attaque, la première étape est de pouvoir la détecter. Dans les contre-mesures, il importe donc d’avoir des outils permettant la surveillance du trafic et/ou des systèmes de détection voire de prévention d’intrusion.

Une fois l’attaque détectée, il faut y réagir, c’est-à-dire l’analyser et arriver à l’arrêter, en y apportant une réponse. Cette procédure doit permettre la mobilisation est personnes et des outils nécessaires, en situation d’urgence. L’objectif est de minimiser les dégâts de l’attaque.

Enfin, en parallèle ou après l’étape de réaction, vient l’étape de récupération, visant à rétablir le bon fonctionnement de l’organisation. Cela peut s’effectuer par exemple en basculant sur des infrastructures de backup, ou en restaurant des sauvegardes pour remplacer des données perdues ou altérées.

4.1.6. Amélioration continue

Comme déjà mentionné plusieurs fois, une telle analyse ne doit pas aboutir sur un document figé, mais sur un processus d’analyse et de remise en question régulière.

Via une veille technologique sérieuse et une analyse du fonctionnement quotidien des systèmes et des contre-mesures, les responsables des systèmes informatiques veilleront à adapter les processus et contre-mesures à l’évolution des menaces, tout en s’assurant de leur bon fonctionnement au jour le jour.

Bibliographie

[1] Annick Baudet, Comment réaliser une évaluation des risques informatiques, janvier 2022, consulté en février 2024

[2] Center for Cybersecurity Belgium, Baseline Information Security Guidelines (BSG) avec RGPD, 2019, consulté en février 2024

[3] Chloé Ricous, OpenClassrooms, cours “Analysez et gérez les risques S.I.”, oct. 2020, consulté en fév. 2024

[4] Zerto, Risk Assessment, BIA, SLAs, RTOs, and RPOs: What’s the Link? MTD and MTDL, nov. 2022, consulté en fév. 2024